Recall actions of vehicles into the workshops, e.g. for eliminating faults in the software of a control device, are cost- and time-intensive for the vehicle manufacturer and for the customer. However, there is no technical necessity for eliminating faults in the workshop because a diagnosis or a software update of the control device could also be performed by remote control via an air interface. However, the software should not be applied directly to the control device by mobile radio via an air interface since mobile radio links are associated with high latency and failure times and thus there is a high probability of a faulty installation of the software. The aim is achieved more completely by first downloading the software via the air interface and only after a complete download of the software to install the latter autonomously in the vehicle so that there does not have to be a stable mobile radio link during the writing phase.
From the prior art it is known that a diagnosis of vehicle components by means of a so-called diagnostic runtime script for describing diagnostic and test runs, such as e.g. by the Standard Open Test Sequence Exchange (OTX), can be performed. The diagnostic scripts are then executed at the vehicle by means of a so-called runtime API (API=Application Programming Interface) and a runtime environment. A performance control device in the vehicle can then be used for planning the sequence of various diagnostic runtime scripts.
German laid-open patent application DE 102011100106 A1, for example, describes a method and system for diagnosis of a vehicle component with a server which provides a diagnostic runtime script and an associated execution parameter of a diagnostic device in the vehicle. A script generating device is also provided in order to generate the diagnostic runtime script from a script language, e.g. OTX, and to send it to the server.
However, greater flexibility would be desirable with regard to the type of remote-controlled orders which are sent to the vehicle via the air interface. This would lead to, among other things, a generic transformability of diagnosis-specific use cases such as, e.g., reading out error stores, ECU flashing or ECU configuration (ECU=Electronic Control Unit).